A beautiful, interactive Terminal UI for analyzing Ruby gem dependencies and quickly identifying security risks in your projects.
-
Interactive Tab-Based TUI: Clean, modern interface with 4 main screens
- [Gems] - First-level gem list with versions and update status
- [Search] - Real-time gem search across all dependencies
- [CVE] - Vulnerability detection and reporting
- Gem Details - Full dependency tree visualization
-
Dependency Visualization: See forward and reverse dependency trees with version info
-
Vulnerability Detection: Identify known CVEs and affected gem versions
-
Group-Based Analysis: Understand gem scope (default, development, test, production)
-
Version Management: See installed versions, latest available, and outdated gems
-
Direct Links: Quick links to rubygems.org and GitHub repositories
-
AI-Ready Reports: Export data in JSON format for AI agents and automated tools
If you're integrating gemtracker into automated systems, CI/CD pipelines, or building AI-powered recommendations, see AI_GUIDE.md for:
- JSON parsing strategies
- Status assessment frameworks
- Recommendation decision trees
- Integration patterns with code examples
- Best practices for AI-powered analysis
Use the gem-check Claude Code skill for interactive gem analysis:
/gem-checkThis skill provides:
- Security-first analysis - Prioritize CVE fixes with severity levels
- Smart prioritization - First-level dependencies before transitive
- Real-world workflows - Guided upgrade paths for different scenarios
- Interactive help - Ask follow-up questions about specific gems
For complete documentation, see the gem-check skill guide.
Examples:
/gem-check # Analyze current project
/gem-check ~/my-rails-app # Analyze specific project
# After running, you can ask:
"Help me upgrade Rails safely"
"What are the top 3 things I should fix?"
"Create a prioritized upgrade plan"
brew tap spaquet/gemtracker
brew install gemtrackerTo upgrade:
brew upgrade gemtrackerDownload the latest release:
# For x86-64
curl -L https://github.com/spaquet/gemtracker/releases/download/v1.0.0/gemtracker_linux_amd64.tar.gz | tar xz
# For ARM64
curl -L https://github.com/spaquet/gemtracker/releases/download/v1.0.0/gemtracker_linux_arm64.tar.gz | tar xzOr build from source:
git clone https://github.com/spaquet/gemtracker
cd gemtracker
make buildDownload the latest release from GitHub Releases:
gemtracker_windows_amd64.zipfor x86-64gemtracker_windows_arm64.zipfor ARM64
Extract the ZIP file and add the directory to your PATH, or place gemtracker.exe in a directory already in your PATH.
If you prefer not to use Homebrew:
# For Intel (x86-64)
curl -L https://github.com/spaquet/gemtracker/releases/download/v1.0.0/gemtracker_darwin_amd64.tar.gz | tar xz
# For Apple Silicon (ARM64)
curl -L https://github.com/spaquet/gemtracker/releases/download/v1.0.0/gemtracker_darwin_arm64.tar.gz | tar xzRequires Go 1.24 or later:
git clone https://github.com/spaquet/gemtracker
cd gemtracker
make build
./gemtracker# Analyze current directory (looks for Gemfile.lock, gems.locked, or .gemspec)
gemtracker
# Analyze specific project
gemtracker /path/to/project
# Analyze specific Gemfile.lock directly
gemtracker /path/to/project/Gemfile.lock
# Analyze gem project with .gemspec (enriches dependencies from RubyGems API)
gemtracker /path/to/gem-project
# Expand tilde for home directory
gemtracker ~/my-rails-app
# Show version
gemtracker -v
gemtracker --versionSupported Input Files (auto-detected in this priority order):
- Gemfile.lock - Resolved dependencies with exact versions (recommended)
- gems.locked - Alternative lock file format
- .gemspec - Gem specification file (enriches from RubyGems API, see Known Limitations)
Generate non-interactive reports for continuous integration pipelines and compliance sharing:
# Generate human-readable text report to stdout
gemtracker --report text /path/to/project
# Export as CSV for compliance managers
gemtracker --report csv --output gems-report.csv
# Export as JSON for CI/CD pipeline processing
gemtracker --report json | jq '.summary'
# Save JSON report to file
gemtracker --report json --output gems-report.json
# Include verbose logging with report
gemtracker --report text --verbose /path/to/projectSupported Formats:
-
text - Human-readable report with sections for vulnerable gems, outdated gems, and full gem list
- Perfect for: Code review, team communication, build logs
- Output: Formatted text with clear sections and summaries
-
csv - Comma-separated values for spreadsheets and compliance tools
- Perfect for: Compliance managers, risk assessment, audit trails
- Columns: Name, Version, Groups, Direct Dependency, Outdated, Latest Version, Vulnerable, Vulnerability Info
-
json - Machine-readable format for automation and CI/CD integration
- Perfect for: Pipeline parsing, metrics collection, automated workflows
- Contains: Full gem details, vulnerability info, summary statistics
Output Options:
- No
--outputflag - Report prints to stdout (useful for piping and CI/CD logs) --output PATH- Report saved to specified file--verbose- Include detailed logging to~/.cache/gemtracker/gemtracker.log
Exit Codes:
- 0 - Success (no errors)
- 1 - Error (e.g., invalid format, missing Gemfile.lock)
CI/CD Examples:
GitHub Actions:
- name: Check gem vulnerabilities
run: gemtracker --report json . | jq '.summary'CircleCI:
- run:
name: Generate gem report
command: gemtracker --report csv --output gems-report.csvGitLab CI:
check_gems:
script:
- gemtracker --report text --output gems-report.txt
artifacts:
paths:
- gems-report.txtOnce running, use these keys:
- Tab / Shift+Tab - Switch between screens ([Gems] β [Search] β [CVE])
- / - Jump directly to Search screen
- β / β - Move selection up/down
- Enter - Select gem to view details
- Tab - Toggle between dependency sections
- β / β - Scroll through dependencies
- Esc - Return to previous screen
- q / Ctrl+C - Quit gemtracker
The gem list shows:
# Gem Name Installed Latest Groups Status
ββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
1 rails 7.1.2 7.2.0 default β 7.2.0
2 devise 4.9.3 latest default β
3 rack 2.1.2 latest default β CVE
Groups column shows where gems are used:
- default - All environments (production, staging, development)
- development - Development only
- test - Test only
- production - Production only
Important: A vulnerability in a
testordevelopmentgem doesn't affect production if not used there.
Status column shows:
- β - Up to date, no vulnerabilities
- β version - Newer version available (outdated)
- β CVE - Known vulnerabilities detected
The CVE screen shows all known vulnerabilities:
- CVE ID - Vulnerability identifier (e.g., CVE-2021-22942)
- Gem - Name of the affected gem
- Version - Version range affected
- Description - What the vulnerability does
- Status - Whether gem is directly used or transitive
Each gem in the [Gems] tab shows a health indicator (colored dot) that reflects the gem's maintenance status. gemtracker fetches this data from RubyGems and GitHub APIs to help you assess dependency health:
Health Levels:
-
π’ HEALTHY - Actively maintained gem
- Activity within the last year (release or GitHub commit)
- Multiple maintainers (2+)
- Regular updates and engagement
-
π‘ WARNING - Gem with maintenance concerns
- No activity in the last 1-3 years, OR
- Single maintainer (even if recent activity)
- May still receive occasional updates
-
π΄ CRITICAL - Potentially dead or unmaintained gem
- No activity for 3+ years
- Archived or disabled on GitHub
- Essentially abandoned
Gem Details include full health statistics:
- Last release date
- GitHub stars and watchers
- Open issues count
- Number of active maintainers
- Archived status (if applicable)
Why Health Matters:
- A "CRITICAL" gem may indicate security risks if vulnerabilities go unpatched
- Unmaintained gems may have compatibility issues with new Ruby/Rails versions
- "HEALTHY" gems are more likely to receive timely security updates
- Different tolerance levels apply: a test-only gem's health matters less than a production core dependency
Note: Health data is fetched asynchronously in the background. If GitHub rate-limited, cached data from the last 24 hours is used.
gemtracker automatically caches analysis results for faster subsequent loads:
- Cache Location:
~/.cache/gemtracker/ - Cache Per Project: Each project's Gemfile.lock gets its own cache file
- Smart Invalidation: Cache is automatically invalidated when Gemfile.lock is modified
- No Manual Cleanup: Old cache files are harmless and can be safely ignored
Example with multiple projects:
~/.cache/gemtracker/
βββ Gemfile.lock_1234.json # Project A cache
βββ Gemfile.lock_5678.json # Project B cache
βββ Gemfile.lock_9012.json # Project C cache
When you re-open a project you've analyzed before, if Gemfile.lock hasn't changed, analysis loads instantly from cache β‘
Cache is refreshed when:
- You run
bundle installorbundle update - You edit your
Gemfile(which updates Gemfile.lock) - The Gemfile.lock file modification time changes
To manually clear cache for a specific project:
rm ~/.cache/gemtracker/Gemfile.lock_*.json-
Navigate to a Ruby project with
Gemfile.lock:cd ~/my-rails-app
-
Launch gemtracker:
gemtracker
-
Browse gems:
- [Gems] tab shows all first-level dependencies
- Press Enter on any gem to see its full dependency tree
- Check Groups column to assess vulnerability impact
-
Search for specific gems:
- Press / or click [Search] tab
- Type gem name to filter in real-time
- Press Enter to view details
-
Check vulnerabilities:
- Click [CVE] tab to see all vulnerabilities
- Filter by gem in [Search] tab
- Check if vulnerable gems are in production
gemtracker fetches repository metadata (push date, stars, issues, archive status) from GitHub to assess gem health. This requires API calls, which have rate limits:
| Scenario | Rate Limit | Requests Needed |
|---|---|---|
| Without token | 60 requests/hour | Up to 189+ (one per gem) |
| With GITHUB_TOKEN | 5,000 requests/hour | 1-2 (batched GraphQL) |
For projects with 100+ gems, a token is highly recommended to avoid hitting rate limits.
GitHub recommends fine-grained personal access tokens over classic tokens. They're more secure and easier to manage.
Steps:
-
Go to GitHub Settings β Personal Access Tokens β Fine-grained tokens
- Or: Click your profile β Settings β Developer settings β Personal access tokens β Fine-grained tokens
-
Click "Generate new token"
-
Configure the token:
- Token name:
gemtracker(or any descriptive name) - Expiration: Choose 30/60/90 days or non-expiring (for regular use)
- Resource owner: Your GitHub account (or organization if using org repos)
- Repository access: Select "Public Repositories (read-only)"
- gemtracker only needs to read public repository metadata, not write
- Token name:
-
Permissions: Leave all permissions unchecked
- Public repository metadata is accessible without explicit permissions
- No additional scopes needed
-
Click "Generate token" and copy the token (you'll only see it once!)
-
Store safely:
- Don't commit to git or share
- Keep in a secure password manager
- You can revoke it anytime at the same URL
Set the token as an environment variable before running gemtracker:
macOS/Linux:
export GITHUB_TOKEN="github_pat_xxxxxxxxxxxx"
gemtrackerPersistent (add to your shell profile):
# Add to ~/.zshrc, ~/.bashrc, or ~/.bash_profile
export GITHUB_TOKEN="github_pat_xxxxxxxxxxxx"Then reload:
source ~/.zshrc # or ~/.bashrcWindows (PowerShell):
$env:GITHUB_TOKEN = "github_pat_xxxxxxxxxxxx"
gemtrackerVerify it's working:
# Check if token is set
echo $GITHUB_TOKEN
# Run gemtracker - health check should now fetch GitHub data much faster
gemtracker- Fine-grained tokens limit access to public repos only (safer than classic tokens)
- No write permissions needed - token can only read repository metadata
- Automatic expiration - GitHub automatically removes unused tokens after 1 year
- Easy to revoke - Delete token anytime from GitHub Settings
- Never commit - Keep out of git repositories and config files
Even with a token, rate limits can be hit if analyzing very large projects (500+ gems) rapidly. If this happens:
- Wait 1 hour for limits to reset
- Or reduce analysis frequency (health data is cached for 12 days)
- Or spread analysis across multiple sessions
gemtracker includes optional error tracking via Sentry to help improve reliability:
- Completely Optional - Not enabled by default
- No Data Without Your Consent - Only enabled if you set
SENTRY_DSNenvironment variable - Works Offline - If Sentry is unavailable, gemtracker continues normally
- Not Required - Development and self-built versions work perfectly without it
To enable error tracking (usually only in official releases):
export SENTRY_DSN="your-sentry-dsn"
gemtrackerIf the env var is not set, error tracking is completely disabled. This is the default for:
- Self-built versions from source
- Development installations
- Local development
make buildmake build-releaseBuilt binaries include git commit hash and build date. To build with custom version:
VERSION=1.0.0 COMMIT=abc123 DATE=2026-04-04 make build- Provide fast, actionable insights into gem dependencies
- Help identify security and compliance risks early
- Support easy integration into CI/CD pipelines
- Beautiful, intuitive UI that developers love using
- Minimal dependencies and fast performance
- Language: Go 1.24+
- TUI Framework: BubbleTea + Lipgloss (charmbracelet)
- Data Source: rubygems.org API + Gemfile.lock parsing
- Go 1.24 or later
- Make
git clone https://github.com/spaquet/gemtracker
cd gemtracker
make buildmake testgemtracker uses golangci-lint for comprehensive code quality checks. These run automatically before pushing via a git hook to catch issues early.
First, install golangci-lint:
# Using Homebrew (macOS)
brew install golangci-lint
# Or using the official installer
curl -sSfL https://raw.githubusercontent.com/golangci/golangci-lint/master/install.sh | sh -s -- -b $(go env GOPATH)/bin# Run linter
make lint
# Run tests
make test
# Or run both before committing
make lint && make testA git pre-push hook automatically runs tests and linter before pushing to prevent CI failures:
git push
# Output:
# π Running linter...
# β Linter passed
# π§ͺ Running tests...
# β Tests passed
# β
All checks passed! Pushing...To skip the hook (not recommended):
git push --no-verifyRequired before PR submission:
- β
All tests must pass:
make test - β
Linter must pass:
make lint
These checks run automatically in GitHub Actions when you push, but fixing them locally first via the pre-push hook prevents CI failures.
gemtracker/
βββ cmd/gemtracker/ # CLI entry point
βββ internal/
β βββ gemfile/ # Parsing & analysis
β β βββ parser.go # Gemfile.lock parser
β β βββ analyzer.go # Dependency analysis
β β βββ outdated.go # Version checking
β β βββ vulnerabilities.go # CVE detection
β βββ ui/ # Terminal UI
β βββ model.go # BubbleTea model
β βββ update.go # Message routing
β βββ view.go # Screen rendering
β βββ styles.go # Colors & themes
βββ Makefile # Build & test
gemtracker follows semantic versioning. New versions are released when features are added or bugs are fixed. Check the releases page for the latest version.
To check your installed version:
gemtracker --version- Homebrew users:
brew upgrade gemtracker - Direct download users: Check releases page and re-download the latest binary
Once gemtracker has stable releases, we plan to submit it to homebrew/homebrew-core, allowing installation with just brew install gemtracker (no tap needed).
-
Gemspec-Only Projects: When analyzing
.gemspecfiles withoutGemfile.lock:- Dependency versions are not guaranteed (shown as
?when unavailable) - "Used By" relationships may be incomplete (would require full lock file for complete reverse dependency graph)
- Forward dependencies are fetched from RubyGems API, but version resolution is limited
- Recommendation: Generate a
Gemfile.lockwithbundle lockfor complete analysis
- Dependency versions are not guaranteed (shown as
-
Outdated version checking requires network access
-
CVE database is static (not real-time updated)
-
No support for Gemfile global options or git/path sources yet
- CONTRIBUTING.md β How to contribute and code quality requirements
- CHANGELOG.md β Version history and what's new in each release
- RELEASE_GUIDE.md β How to make releases and manage the distribution pipeline
- SECURITY.md β Security policy and vulnerability reporting
- CLAUDE.md β Development guidelines for contributors
Please report security vulnerabilities privately using GitHub Security Advisory. See SECURITY.md for details.
See LICENSE file for details.
Contributions are welcome! Please feel free to submit a Pull Request.
- Found a bug? Open an issue
- Feature request? Open a request
- Want to contribute? See CONTRIBUTING.md for guidelines
- Code quality requirements? See CONTRIBUTING.md β Code Quality
- Follow updates? Check out @stpaquet on X
Make sure you're in a Ruby project directory with Gemfile.lock, or specify the path:
gemtracker /path/to/projectBuild using make build instead of go build to get proper version info from git.
Your terminal may not support 256 colors. Try:
TERM=xterm-256color gemtrackerCheck the built-in help or open an issue on GitHub.